Scalable Vector Graphics (SVG) is an Extensible Markup Language (XML) based language for representation of static and dynamic vector graphics. SVG is vector-based which means that the content is not made for certain screen resolutions but can be easily scaled. SVG is standardized by the World Wide Web Consortium (W3C). The mobile profile of SVG version 1.1 was adopted by 3GPP Release 5 and it is today supported by roughly 100 million mobile handsets.
SVG Tiny 1.2 [1] is a more powerful version of SVG that is specifically designed for mobile devices and terminals. It is currently a W3C candidate recommendation and has been adopted by 3GPP Release 6. Support for a variety of new multimedia features, including full control of audio and video, is included along with micro Document Object Model (μDOM) and scripting.
In addition to being a media type for vector graphics, SVG can also be used as a scene description language, where a scene can be composed temporally as well as spatially. In fact, SVG Tiny 1.2 has been adopted as the presentation format for the 3GPP work item on Dynamic and Interactive Multimedia Scenes (DIMS) as well as for the Open Mobile Alliance (OMA) work item on Rich-Media Environment (RME). The standardization of DIMS has been finalized in 3GPP Release 7, whereas OMA is still working on finalizing RME. For DIMS (and also for RME), the main competing proposals were the Mobile Open Rich media Environment (MORE) [2] building on technologies from W3C and the Lightweight Application Scene Representation (LASeR) [3] standardized by MPEG. Both use SVG Tiny 1.2 as basis.
DIMS (RME) content, as opposed to pure SVG content, can be streamed using the Real-time Transport Protocol (RTP) [4]. The rendered SVG document is referred to as an SVG scene and will typically be updated with smaller scene updates. MORE and LASeR specify how SVG scenes can be transported over RTP. The mechanisms for scene updates are conceptually similar, albeit not identical. LASeR specifies its own mechanisms, whereas MORE uses Remote Events for XML (REX) [5] by W3C.
The ability to tune-in and the ability to recover from error by tuning-in are very important in DIMS, in particular when unreliable protocols as RTP are used. When an error occurs the processing terminal may use a next so-called random access point (RAP) to recover from the error. This RAP is decoded the same way as if the terminal was tuning in for the first time and everything from the old scene is deleted and a new tune-in is performed.
Another important feature of DIMS is the ability to combine streams from different sources, even sent over different protocols. A DIMS scene in the primary stream may invoke a secondary stream, which can modify the original scene.
Today, a tune-in point (RAP) in the secondary stream must contain information about the entire scene. This is very inefficient especially when the primary stream is delivered reliably and the secondary stream unreliably. This means that with such a prior art RAP, even parts of the scene received reliably will be re-sent in the tune-in points of the secondary stream.